Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-frnetmib-virtual-sma-00.txt < prev next >

Wrap

Text File | 1993-06-16 | 38.7 KB | 1,065 lines

Draft Service Management Architecture June 1993 Service Management Architecture for Virtual Connection Services June 14, 1993 Frame Relay Service MIB (frnetmib) Working Group Kenneth R. Rodemann AT&T Bell Laboratories krr@qsun.att.com 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Rodemann Expires Dec 19, 1993 [Page 1] Draft Service Management Architecture June 1993 2. Abstract This document presents the Service Management Architecture, an architectural framework for defining SNMP MIB modules for Customer Network Management (CNM) of network services over connection-oriented networks. The work is motivated by the fundamental differences in management views and functionality between a service provider and a service customer. Differences between service provider and service customer include whole-network vs. network-portion view, direct vs. indirect management, and physical vs. logical view. These fundamental differences suggest a difference in philosophy between Service Management and Device Management. Much work has been done and experience gained in writing Device MIB modules for hands-on management of physical devices, but defining Service MIB modules is a relatively new area and requires the development of a new architectural framework. Rodemann Expires Dec 19, 1993 [Page 2] Draft Service Management Architecture June 1993 3. Introduction This document presents the Service Management Architecture, an architectural framework for defining SNMP MIB modules for Customer Network Management (CNM) of network services over shared networks. Network providers offer a myriad of network services, such as X.25, SMDS, Frame Relay, and ATM. Some of these provide connection-oriented service, while others provide connectionless service. CNM services are becoming an important extension of these transport services to provide customers with a management window into their portion of the shared service. This document focuses on an SNMP-based architectural framework for CNM of connection-oriented network services. The purpose of this work is to identify the notion of a Service MIB module, and to define an architectural framework for its definition that will permit easy extensibility and interoperability across various network services. In order to explore and understand how Service and Device management differ, consider the following fundamental differences in network management functionality between a network service provider and a service customer. First, service providers are responsible for managing the entire shared network as a whole, while service customers only view and manage their individual portions of the shared service. Because they have a restricted view of the network, customers are unable to perform certain network management functions in the shared environment. For example, a customer which sets routes for optimized throughput of their own traffic may disrupt another customer's traffic. Only the service provider, with a complete view of the entire network, is in a position to determine routes that allow provisioned access to network resources for all customers. A second fundamental difference in management functionality is that service providers manage the network internals directly, while customers manage their portion of the shared network indirectly. The service provider is responsible for the overall operation of the shared network, so any management control offered to customers must first be approved (perhaps manually) by the service provider before the control request takes effect in the network. Rodemann Expires Dec 19, 1993 [Page 3] Draft Service Management Architecture June 1993 Finally, while service providers see a physical view of the network, customers see a logical view. This logical view includes the customer's configuration of service access points (ports) and the virtual connections that run between these ports. The customer does not see the individual network switches along the paths of its virtual connections---setting up physical routes is a responsibility of the service provider. These fundamental differences in network management functionality suggest that there is a wholly different philosophy between Service Management and Device Management. A Device MIB module allows for hands-on management of a physical entity. A Service MIB module provides to customers a logical view of the customer's portion of a shared network service by modeling the service, not the underlying implementation or devices. Much work has been done and experience gained in writing Device MIB modules for hands-on management of physical devices, but defining Service MIB modules is a relatively new area and requires the development of a new architectural framework. Rodemann Expires Dec 19, 1993 [Page 4] Draft Service Management Architecture June 1993 4. Service Architecture A connection-oriented network service offered by a service provider can be viewed as a logical configuration of service access points (ports), access channels, and virtual connections (see Figure 1). Note that the term 'port' is used instead of 'interface' to distinguish between a service access point and a physical device access point. +---------------------+ | | ###@=====================@### |\ | | =================== | | \| | @### | /| | =================== | |/ | ###@=====================@### | | +---------------------+ Where @ is a service access point (port) ### is an access channel === is a virtual connection through the service provider's network Figure 1: Logical view of a connection-oriented network service, including service access points (ports), access channels, and virtual connections. The service provider manages the internals of the network (switch and trunk acquisition/placement, virtual connection provisioning/routing, internal fault detection/correction, etc.), so the service customer need not be concerned with such aspects. Instead, the service customer views and indirectly manages the components in its logical view of the service offering. Rodemann Expires Dec 19, 1993 [Page 5] Draft Service Management Architecture June 1993 A customer may subscribe to the services of more than one service provider, with end-to-end virtual connections that span multiple service providers' networks. These multi-segment virtual connections can be viewed as a concatenation of individual service-provider views (see Figure 2). +---------+ +---------+ +---------+ | Service | | Service | | Service | | Provider| | Provider| | Provider| ------+ | A | | B | | C | +------ | | | | | | | | Cust |###@=========@###@=========@###@=========@###| Cust | | | | | | | | ------+ | | | | | | +------ +---------+ +---------+ +---------+ Figure 2: Logical view of a customer's end-to-end virtual connection that spans across multiple service providers' networks. The end-to-end view is a concatenation of individual service-provider views. The next section discusses the Service Management Architecture, modeled upon the service architecture just presented. Rodemann Expires Dec 19, 1993 [Page 6] Draft Service Management Architecture June 1993 5. Service Management Architecture We previously discussed fundamental differences in network management functionality between a service provider and a service customer. These fundamental differences led to a distinction between a Device MIB module and a Service MIB module. A Service MIB module models the offered service, so we now apply the preceding Service Architecture to derive a generic Service MIB Module Architecture. There exist two views of virtual connections within the Service Architecture: service-provider views and customer end-to-end views. Service-provider views consist of single-segment virtual connections established through a single service provider's network. Customer end-to-end views consist of multi-segment end-to-end virtual connections that span across multiple service providers' networks. This end-to-end view represents a multi-segment virtual connection as a concatenation of individual service-provider segments. We first consider the service-provider view, then briefly outline the customer end-to-end view. 5.1 Service-Provider View The Service Architecture identifies three types of service objects within the service-provider view: service access points (ports), access channels, and virtual connections. A customer's logical configuration of service objects can be defined in generic terms, without knowledge of the underlying datalink protocol (X.25, Frame Relay, ATM, etc.) of the service offering. Defining the configuration in such a protocol-generic fashion will give to customers a consistent end-to-end view of interworking services. The first issue is how to identify a customer's service objects. For protocol-generic identification, the Service Management Architecture uses logical identifiers as follows: Ports - Since customers view a provider's service as a single entity, port id is a logical identifier unique within the service provider's offering. The service provider is free to choose port identifiers as it sees fit. Rodemann Expires Dec 19, 1993 [Page 7] Draft Service Management Architecture June 1993 Access Channels - The Service Management Architecture does not specify an identification scheme for access channels. Because of the one-to-one association of access channels to ports, the Service Management Architecture places access channel reference information with the associated port. Virtual Connections - Virtual connections are logical data transport connections between a pair of ports. Each end of a virtual connection is separately identified by a tuple (port id, VC id). The VC id is a logical identifier unique to the associated port, and is assigned by the service provider as it sees fit. The service provider *may* map the VC id directly to the addressing scheme used in the underlying protocol (e.g., DLCI for Frame Relay), but this is not necessary. The next issue is how to structure the MIB information within the Service Management Architecture. Service objects have certain attributes that are protocol-generic, and other attributes that are protocol-specific. For example, protocol-generic attributes for virtual connections include connection status and the identification of the remote end of the connection. Protocol-specific attributes for virtual connections include the underlying protocol's address of the connection (DLCI for Frame Relay, VPI/VCI for ATM) and protocol-specific service attributes (CIR for Frame Relay, traffic class for ATM). To provide consistent views across interworking of services, the top level of the Service Management Architecture consists of protocol-generic MIB modules that contain generic object information and references to protocol-specific MIB modules. The Management Architecture includes a protocol-generic MIB module for ports and a protocol-generic MIB module for virtual connections. Rodemann Expires Dec 19, 1993 [Page 8] Draft Service Management Architecture June 1993 First, consider a protocol-generic MIB module for ports. A port has a logical identifier. A port may have a global address. A port has a current state. A port interface is either User-Network (UNI) or Network-Network (NNI). A port may have associated location information and contact information. A port has protocol-specific port information. A port has an associated physical access channel. A port runs a specific link management protocol over the access channel. So, here is a first pass for a protocol-generic port MIB module: + port id + global addressing info + port status info + UNI/NNI indicator + contact/location info + reference to (OID of) protocol-specific port MIB entry (Frame Relay, ATM, X.25, etc.) + reference to (OID of) specific physical layer MIB entry (DS1/E1, DS3, etc.) + reference to (OID of) specific link management MIB entry (LMI, ILMI, Annex A, Annex B, etc.) Just a footnote on the difference between port id and global address: Port id is a logical identifier unique only within a given service-provider's network (i.e., has local significance), while a global address is a port identifier unique across all service providers' networks (i.e., has global significance). The protocol-generic port MIB module ties in with the Interfaces Group as follows. A port is viewed as an interface to the service-provider's network, so ifIndex = port id. The value of ifType is the assigned value for the type of port, e.g., Frame Relay, ATM, X.25, etc. And ifSpecific is an OID that points to the entry in the protocol-generic port MIB module. Rodemann Expires Dec 19, 1993 [Page 9] Draft Service Management Architecture June 1993 Next, consider a protocol-generic MIB module for virtual connections. A virtual connection has a local port id and VC id. A virtual connection has a remote port id and VC id. A virtual connection has a current state. A virtual connection may be either Permanent or Switched. A virtual connection has protocol-specific virtual connection information. So, here is a first pass for a protocol-generic virtual connection MIB module: + local port id + local VC id + remote port id + remote VC id + VC status info + Permanent/Switched VC indicator + reference to (OID of) protocol-specific virtual connection MIB entry (Frame Relay, ATM, etc.) Figure 3 shows the Service Management Architecture MIB module structure, including the relationships between the Interfaces Group module, protocol-generic MIB modules, protocol-specific MIB modules, and access channel MIB modules. 5.2 Protocol-Generic/Protocol-Specific Relationship This section further explores the relationship between the protocol-generic tables and the protocol-specific tables. To set the stage, first consider differences in functionality between the two sets of tables. The protocol-generic tables serve two functions: (1) to provide a consistent structure for defining protocol-specific MIB module suites (i.e., separating into distinct MIB tables the management information for ports, virtual connections, access channels, and link management protocols), and (2) to provide the topological glue for defining protocol-generic virtual connection configuration. The function of the protocol-specific tables is to provide the specific details of the particular protocol service. Rodemann Expires Dec 19, 1993 [Page 10] Draft Service Management Architecture June 1993 protocol-generic proto-specific Interfaces port module port module ------------------- ------------------- -------------- | ifIndex=port id | -->| port id | -->| e.g. | |-----------------| | |-----------------| | | FR | | . | | | . | | | ATM | | : | | | : | | | X.25 | |-----------------| | |-----------------| | -------------- | ifType | | | proto-specific | | | (e.g., FR, ATM) | | | port entry OID -+-- physical layer |-----------------| | |-----------------| -------------- | . | | | physical layer | |->| e.g. | | : | | | entry OID -----+-- | DS1/E1 | |-----------------| | |-----------------| | DS3 | | ifSpecific OID -+-- | link management | -------------- ------------------- | entry OID -----+-- ------------------- | link management | -------------- -->| e.g. | | LMI | | ILMI | | Annex A | -------------- protocol-generic proto-specific VC module VC module ------------------- -------------- | local port id | -->| | |-----------------| | | e.g. | | local VC id | | | FR | |-----------------| | | ATM | | . | | | X.25 | | : | | | | |-----------------| | -------------- | proto-specific | | | VC entry OID -+-- ------------------- Figure 3: Service Management Architecture MIB module structure showing relationships between the Interfaces Group module, protocol-generic MIB modules, protocol-specific MIB modules, and access channel MIB modules. Rodemann Expires Dec 19, 1993 [Page 11] Draft Service Management Architecture June 1993 The protocol-generic tables and the protocol-specific tables have a hierarchical relationship, with the protocol-generic tables being at a "higher" level than the protocol-specific tables. However, this does not imply that the protocol-specific tables are fully reliant on the protocol-generic tables. The Management Architecture permits protocol-specific MIB module suites to be self-contained, i.e., a protocol-specific suite may contain its own configuration information for correlation of service objects without the need for indirection through the protocol-generic tables. Of course, correlation of interworking service objects (for example, the remote end of an interworking virtual connection) would require a reference through the protocol-generic VC table. Recall that the protocol-generic tables contain downward references (OIDs) to entries in protocol-specific tables. To allow for management of interworking service objects, the reverse references must also be in place, i.e., upward references from the protocol-specific tables to entries in the protocol-generic tables. These upward references may be either OIDs or indexes into the protocol-generic tables. For protocol-specific VC tables, it is recommended that an interworking flag or some other indication be used to tell whether a virtual connection is an interworking connection or not. If the connection is a non-interworking connection, then the remote end can be referenced within the given protocol-specific suite; else, the remote end must be referenced through the protocol-generic tables. The Service Management Architecture permits protocol-specific suites to define their own table indexing, independent of the protocol-generic indexing. For example, a Frame Relay suite may index a PVC table on port/DLCI, while an ATM suite may index a VPI connection table on port/VPI and a VPI/VCI connection table on port/VPI/VCI. The following shows an example scenario of the relationship between protocol-generic tables and protocol-specific tables. The example also demonstrates how the Service Management Architecture provides a consistent management view of a service provider's interworking service. Figure 4 gives the configuration of a customer with 5 ports, 3 of which are Frame Relay ports (P1, P2, P3) and 2 are ATM Rodemann Expires Dec 19, 1993 [Page 12] Draft Service Management Architecture June 1993 ports (P4, P5). Of the customer's 4 virtual connections, 2 are pure Frame Relay connections, 1 is a pure ATM connection, and 1 is an interworking connection between Frame Relay and ATM. The customer accesses the service via 2 different types of access channels running various link management protocols. +---------------------+ FR P1| VC1 VC1 |P2 FR DS1 ###@=====================@### DS1 LMI |\ | Annex A | =================== | | VC2 VC1\|P3 FR | @### DS3 | VC1 VC2/| Annex B | =================== | ATM P4|/ |P5 ATM DS3 ###@=====================@### DS3 ILMI | VC2 VC1 | ILMI +---------------------+ Figure 4: Example customer configuration of an interworking service offered by a service provider. P<n> is the logical port id and VC<n> is the logical port-specific VC id. FR/ATM are the port-specific datalink protocols, DS1/DS3 are the specific physical layers, and LMI/Annex A/ Annex B/ILMI are the specific link management protocols. The protocol-generic port MIB module has 5 entries, and the protocol-generic virtual connection MIB module has 8 entries (one entry for each end of the 4 virtual circuits), as shown in Figure 5. To complete the example, the Frame Relay-specific and ATM-specific virtual connection MIB modules are shown in Figure 6. The example shows the downward and upward references between the protocol-generic and protocol-specific tables (via an index for the Frame Relay suite and an OID for the ATM suite). Both protocol-specific VC MIB modules also indicate if a virtual connection is an interworking connection---with a DLCI value of -1 for the Frame Relay suite, and an interworking flag value of 0 for the ATM suite. Rodemann Expires Dec 19, 1993 [Page 13] Draft Service Management Architecture June 1993 PROTOCOL-GENERIC PORT MODULE (indexed on port-id) ============================ OID of OID of OID of port proto-specific phys layer link mgmt id port entry entry entry --------------------------------------------------------- | 1 |...| *FR port entry #1 | *DS1/E1 #1 | *LMI #1 | | 2 |...| *FR port entry #2 | *DS1/E1 #2 | *Annex A #1 | | 3 |...| *FR port entry #3 | *DS3 #1 | *Annex B #1 | | 4 |...| *ATM port entry #1 | *DS3 #2 | *ILMI #1 | | 5 |...| *ATM port entry #2 | *DS3 #3 | *ILMI #2 | --------------------------------------------------------- PROTOCOL-GENERIC VIRTUAL CONNECTION MODULE (indexed on local-port-id/local-VC-id) ========================================== OID of table local local remote remote proto-specific entry port id VC id port id VC id VC entry ------------------------------------------------------- 1 | 1 | 1 | 2 | 1 |...| *FR VC entry 1 | 2 | 1 | 2 | 3 | 1 |...| *FR VC entry 2 | 3 | 2 | 1 | 1 | 1 |...| *FR VC entry 3 | 4 | 3 | 1 | 1 | 2 |...| *FR VC entry 4 | 5 | 3 | 2 | 4 | 1 |...| *FR VC entry 5 | 6 | 4 | 1 | 3 | 2 |...| *ATM VC entry 1 | 7 | 4 | 2 | 5 | 1 |...| *ATM VC entry 2 | 8 | 5 | 1 | 4 | 2 |...| *ATM VC entry 3 | ------------------------------------------------------- Figure 5: Protocol-generic MIB modules showing table indexing and the downward references within the Service Management Architecture. This example demonstrates how the Service Management Architecture provides a consistent management view of: + interworking datalink protocol connections + various type of physical access channels + various link management protocols Note also how easy it is to integrate new datalink protocol Rodemann Expires Dec 19, 1993 [Page 14] Draft Service Management Architecture June 1993 FR-SPECIFIC VC MODULE (indexed on local-port/local-DLCI) ================================== generic generic table local local remote remote local remote entry port DLCI port DLCI VC id VC id --------------------------------------------------- 1 | 1 | 100 | 2 | 200 | 1 | 1 | ... | 2 | 1 | 110 | 3 | 110 | 2 | 1 | ... | 3 | 2 | 200 | 1 | 100 | 1 | 1 | ... | 4 | 3 | 110 | 1 | 110 | 1 | 2 | ... | 5 | 3 | 200 | 4 | -1 | 2 | 1 | ... | --------------------------------------------------- ATM-SPECIFIC VC MODULE (indexed on local-port/local-VPI/local-VCI) =========================================== OID of table local local local generic I/W remote remote remote entry port VPI VCI VC entry flag port VPI VCI ------------------------------------------------------- 1 | 4 | 100 | 10 | *entry 6 | 0 | 3 | 0 | 0 |...| 2 | 4 | 110 | 10 | *entry 7 | 1 | 5 | 100 | 20 |...| 3 | 5 | 100 | 20 | *entry 8 | 1 | 4 | 110 | 10 |...| ------------------------------------------------------- Figure 6: FR-specific and ATM-specific VC MIB modules using protocol-specific table indexing. Also shown are the upward references within the Service Management Architecture. MIB modules, physical channel type MIB modules, or link management protocol MIB modules into the Service Management Architecture view---just have the appropriate OID value point to the the appropriate entry in the new MIB module. Rodemann Expires Dec 19, 1993 [Page 15] Draft Service Management Architecture June 1993 5.3 Customer End-to-end View The customer end-to-end view provides the correlating information to view end-to-end virtual connections that span through multiple service providers' networks. This end-to-end view represents a multi-segment virtual connection as a concatenation of individual service-provider segments. The section of the Service Management Architecture is very sketchy. An adequate definition of this view requires much more discussion and experience. Here is a sketchy initial stab at the information needed for this end-to-end view. This is not in MIB format, i.e., having a table within a table, but this shows the type of required information for this view. An entry in the end-to-end MIB module may include: + end-to-end VC id + end-to-end VC status info + ordered list of VC Segments: - VC Segment number - VC Segment Provider info - VC Segment status info - point A port id - point A VC id - point B port id - point B VC id Note the use of generic terms "point A" and "point B". The intent is to refrain from using terms like Originating/Terminating and Source/Destination that suggest a master-slave type of relationship. The only relationship to be inferred from the terms point A and point B is the polarization or orientation of individual VC segments, i.e., point B of the i'th segment is attached to point A of the i+1'st segment. Rodemann Expires Dec 19, 1993 [Page 16] Draft Service Management Architecture June 1993 6. Summary This document presents the Service Management Architecture for defining Service MIB modules. The work is motivated by the fundamental differences in management views and functionality between a service provider and a service customer. Differences between service provider and service customer include whole-network vs. network-portion view, direct vs. indirect management, and physical vs. logical view. These fundamental differences suggest a difference in philosophy between Service Management and Device Management. The Service Architecture models a customer's view of a shared network service as a logical configuration of ports, access channels, and virtual connections. A service customer indirectly manages the components within its logical view, not the internals of the shared network. Virtual connections that span across multiple service providers' networks are viewed as concatenations of individual service-provider segments. Modeled upon the Service architecture, the Service Management Architecture presents two views of virtual connections: service-provider views and customer end-to-end views. Service-provider views consist of single-segment virtual connections established through a single service provider's network, while customer end-to-end views consist of multi-segment end-to-end virtual connections that span across multiple service providers' networks. This document discusses more of the service-provider view than it does the customer end-to-end view. The service-provider view consists of protocol-generic MIB modules for defining configuration, with references to protocol-specific MIB modules. This structure, along with the use of protocol-generic port and virtual connection identifiers, provides a clean Service Management Architecture that promotes consistent views across various underlying implementations and interworking of services. Rodemann Expires Dec 19, 1993 [Page 17] Draft Service Management Architecture June 1993 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Kenneth R. Rodemann AT&T Bell Laboratories Room 1F-435A 101 Crawfords Corner Road PO Box 3030 Holmdel, NJ 07733-3030 908-949-6229 krr@qsun.att.com Rodemann Expires Dec 19, 1993 [Page 18] Table of Contents 1. Status of this Memo................................. 1 2. Abstract............................................ 2 3. Introduction........................................ 3 4. Service Architecture................................ 5 5. Service Management Architecture..................... 7 5.1 Service-Provider View.......................... 7 5.2 Protocol-Generic/Protocol-Specific Relationship................................... 10 5.3 Customer End-to-end View....................... 16 6. Summary............................................. 17 7. Security Considerations............................. 18 8. Author's Address.................................... 18 Rodemann Expires Dec 19, 1993 [Page 19]